Note: "suntar" does NOT mean computers by Sun Microsystems, it's "Speranza's un-tar" since it extracts tar archives (i.e. un-tars their contents) created on any UNIX machine (including Sun, but also IBM, HP and others). The application icon is only a graphical joke which does not want to represent the Sun logo.
What's suntar ?
Really, suntar is becoming two things in one. It's a MacBinary, BinHex, uuencode and PackIt extractor, and it's one of the fastest extractors you can find, and one of the few which may convert more files in one operation (only with drag&drop, by now). That may be enough to let you wish use it.
But its original purpose was to communicate, acting as a bridge between a UNIX workstation and the Mac if a few, minimal hardware requirements are met: that is, a physical medium (a mass storage device) must be connected to both machines. That's usually easy with floppy disks but almost any SCSI device may be used instead.
Finally, handling devices requires some bookkeeping: this may be seen as a third personality; some time ago I used suntar to resurrect a SyQuest cartridge which, according to Norton Utilities, was completely lost. That's because all available utilities access the disk at a rather high level, and can't solve even the simplest problems arising at a lower level.
We believe that programs like suntar meant to communcate should disappear in a future world where any computer will exchange data naturally with any computer, but by now computers and their data are often totally incompatible and suntar is useful.
To understand what it does, it's useful to tell how the whole thing started: we had just got the new, wonderful Macintosh LC (it was December 1990ﾉ), but one of us was a student and at the University he had to work on a Sun SPARCstation 1: is it possible to communicate data between the two machines, without using a network or a modem ? The SPARCstation has a 3.5" floppy disk drive, why shouldn't it be possible to save a file on a disk at the University and read it back on our Mac, or vice-versa ? That would be useful both for working (typing a C program at home before compiling it on the Sun) and downloading Mac files from all those ftp-able places in the world.
The Apple SuperDrive can read and write disks in the two IBM formats, 720K and 1440K with MFM encoding: for simplicity and compatibility, all 3.5" drives manufacturers have adopted this de-facto standard, hence there should be no difficulty to read a disk written on any UNIX workstation on a Macintosh with a SuperDrive. Unfortunately, for a while Apple did not adhere to that standard, the 400K and 800K drives used exclusively an Apple proprietary physical encoding called GCR which can't be read or written on a non-Apple disk drive.
But the SuperDrive is compatible, and it's present on all recent Mac models: it's missing only in the older models (128K, 512K, Plus, the SEs built before September 89 and not upgraded with a FDHD kit, and the original Macintosh II without other letters in its name and not upgraded).
Furthermore, with a few exceptions the ancient UNIX hasn't learned yet about floppy disk drives: they must be set up to emulate a tape drive unit, handled by the tar utility. That's good for us, since tar uses a simple, standard format: no allocation tables, inodes and other complex, nonportable data structures, files are stored sequentially preceded by a simple header containing their name and a few informations; for directories there is only the header and contained files are stored separately, using the partial path name from the directory you specified.
So, we wrote suntar, a program which runs on a Macintosh and reads and writes a disk in the physical IBM formats containing data in the logical tar format; thinking that it could be useful to many students having the same problem, we added more features, made it easier to use and released it in Internet.
Usually, we launch suntar and let it perform extractions in background: almost all files arrive with their proper icon and are double-clickable. It's easy to use an application which may recognize file formats without requiring that you tell it which "filter" must be used for each file !
Really, there are three different floppy disk formats you may use on an UNIX workstation in order to exchange data with a Mac:
1) the Macintosh format: we' ve read on magazines about commercial programs which, running on UNIX workstations, should read and write disks in Macintosh format. NeXTStep release 3 includes that capability too, and in the future it might become commonplace.
2) the MS-DOS format: the public domain package "mtools" (or other utilities) can read and write in the MS-DOS format under UNIX, and Apple File Exchange (or PC Exchange or Access PC) can then move the data to your Mac. Inconveniences of such approach are: to move files bigger than a disk is possible but annoying (you must split them); you have no support for Macintosh specific file formats (for example, AFE can translate a MS-DOS ASCII text to a Mac ASCII text, but you must disable such conversion on UNIX files and convert later, or convert twice UNIX->MS-DOS and MS-DOS->Mac); lastly, the portability of UNIX programs is a myth, you get a public domain package in source code but you need the help of an experienced programmer to have it compiled and running.
3) the UNIX formats, that is tar and bar formats. Suntar can read and write such archives, and performs all the most useful file conversions while doing it.
Under UNIX, tar may be used for three purposes:
1) to perform regular back-ups on tape, to be stored and hopefully never used; or to archive rarely used files off-line, on a medium which is cheaper and more capable than a hard disk: that's where the name tar (Tape ARchiver) originally came from.
2) to put together several files into a single file, which may be easier to manage, expecially if you wish to compact it (both the old pack utility and the new compress generate one compressed file per input file).
3) it's the simplest way, and sometimes the only way, to create a physical medium which can be used to distribute programs and data to other computer users.
Suntar was conceived to be mainly a communication program, role 3, allowing Macintosh users to exchange data with UNIX users. It can be used for backups, role 1, but it can't compete with applications written as backuppers. And it may perform role 2 just as well as its two competitors (tar 3.0 and StuffIt Deluxe).
What you need
To exchange data is a difficult art: if you want to fully exploit suntar you should have some basic notions about Mac files: data and resource forks, the MacBinary format (a common way to store a Mac file in an UNIX-style file without losing informations) and so on.
Furthermore, you should know that in text files UNIX separates lines by a Line Feed character while the Mac uses a Carriage Return (MS-DOS uses a CR followed by a LF, just to be incompatible with both).
If your purpose is to download files from ftp-able public domain archives, you should have a bunch of public domain programs to convert file formats:
･ .bin files (and all non-ASCII formats) are MacBinary files, directly converted by suntar; you should not need any of the many small utilities performing the conversion, such as BinHex 5.0 (which is a totally different program from BinHex 4.0)
･ .hqx files may be converted (usually yielding a .sit or .pit) by suntar itself, by BinHex 4.0 or StuffIt, Compact Pro, Downline or many small utilities. Only a few of these programs (e.g. the DA BinHqx) can decode files splitted in several parts, and suntar can't: if you get a set of parts, you may use United or Unity (or any text editor which accepts very large files) to put all parts together (without any extra text: suntar does not skip lines such as '----- end of part 1' if they are between two lines of BinHex data, and signals an error)
･ .pit files were created by PackIt, but StuffIt and Downline too support them, and there is a freeware Unpit (which may create them too). Starting from version 1.2, suntar too can extract them by the "Open file" command
･ .sit files are almost a standard, recognized by several compression programs on the Mac: their originator (StuffIt 1.5.1) or Compact Pro, Disk Doubler and Downline. However, StuffIt has now evolved to a commercial version, StuffIt Deluxe, with new, incompatible compression methods. StuffIt Deluxe 3.0 and the shareware StuffIt Lite 3.0 have more new methods and StuffIt Expander is the only freeware which may decode all of them
･ .cpt files were generated by Compact Pro (once called Compactor); the extract-only versions (cptExpand and Extractor) are freeware. StuffIt Expander too is able to expand cpt files
･ .sea files were created by Compact Pro, StuffIt or DiskDoubler, but they self-extract themselves when you double-click them
･ .gif files are a non-Mac graphical format, supported by many Mac applications and DAs: suntar assigns them the correct type so that graphics programs may recognize them more easily.
･ other files types may be handled by suntar through the suffix table in the options dialog (MacBinary and GIF files are recognized by contents, not by name, so they don't need the "standard" suffix).
If you exchange UNIX files instead of Mac files, you'll need MacCompress which is compatible with the UNIX utility compress (.Z files), or maybe you should use StuffIt Deluxe 3. And obviously you need Macgzip. You might need unshar (to extract .shar files). Suntar, StuffIt, Uutool and other utilities are compatible with uuencode/uudecode.
Usually, suntar automatically converts LF to CR when reading a text file, and using "write ASCII" it converts CR to LF when writing. If a file contains non-ASCII characters (codes bigger than 127, such as ･ or ｩ) suntar may convert them (see the comments in suntar's char table); if that's not enough, you may need some file-conversion applications to solve such problems (sometimes we used Xform, but that was a lot of time ago, there are certainly other utilities for the same purpose).
Finally, DeskZap 1.32 is always handy to change file type and creator (or you may use BunchTyper or similar drag&drop utilities), set the bundle bit (some programs come with an icon which is not shown by the Finder because the author has forgotten to set the bundle bit: in that case, you should also clear the "inited" bit to force the Finder to examine that file again) and perform simple file format conversions (DeskZap 2.0 is more powerful but we don't like its new user interface), and the desk accessory System Errors may tell you the meaning of error codes which suntar prints when something is wrong.
Instructions, UNIX side
You must know the device name of the floppy disk: it's "/dev/rfd0" on a Sun 3, SPARCstation or IBM RISC/6000 (which autosense the density), on Sun 386i it's /dev/rfd0 or /dev/rfdl0 according to the density (1440 or 720k), on other machines it might be /dev/rdsk, /dev/rfp, /dev/rflp, and other characters may be optionally appended meaning the currently used density. That initial 'r' is another attribute (raw), /dev/fd0 is the same device but it's accessed with more software overhead. UNIX should tell you the right name when you type "man fdformat" or "man -k disk", otherwise you may ask to your system administrator, or try to explore the /dev directory (devices usually need no special privilege, and all UNIX commands including cat may access them).
Things are more difficult on a NeXTstation: disk devices require root privileges, and if you simply insert a disk, the system tries to mount it (requiring the proper format, incompatible with tar and even with the format of disks mounted by SPARCstations): that's the simplest way to format a disk (don't use a barium-ferrite disk, which is formatted at 2.88K, if you want to read it on a Mac). To create or read a tar archive, you must launch tar, wait for a dialog which asks for the disk, and now insert it. Under NeXT OS 2.0 and 2.1 the device name was /dev/rfd0h for the internal drive and /dev/rsd1h for an external SCSI drive: BEWARE that /dev/rsd0h is the hard disk, and since you must do that with root privileges a mistyped character may cause the destruction of essential informations, so that you won't be able to boot from the hard disk! ! You should try to read from the device (e.g. by "cat /dev/rfd0h") and be sure that's accessing the floppy disk, before trying to write. Under later versions the device is /dev/rfd0b (the digit may be 0 to 7 and is not a drive number, it's dynamically assigned to disks when they are mounted hence if the NeXT asks for a specific disk that number is already assigned and you should try with another one). Finally, you must eject the disk by typing "disk -e -f /dev/rfd0b". (Thanks to Maurizio De Cecco for part of informations about the NeXT).
You may use disks formatted on the UNIX workstation, on an IBM PS/2 or on the Mac, either under suntar itself or Apple File Exchange or the Finder (1440K only, or, with the Finder of 7.5 or later, also 720K).
Beware: MS-DOS and System 7 have a feature that allows you to use disks having bad sectors, by marking them in the allocation table. A tar disk has no allocation table, any bad sector will be used for data if the archive is long enough to reach that sector. Hence, if you have doubts about the quality of your disks you should initialize them under System 6 or suntar, where initialization fails if there are any bad sectors. Suntar alerts you if a disk contains sectors marked bad by System 7 or MS-DOS; the UNIX command fdformat does not verify the disk.
On the SPARCstation, the typical operations are performed as follows.
Formatting (it requires no parameters):
fdformat
(on a Silicon Graphics formatting is performed by fx -x then answering:
fx: "device-name" = (dksc) fd
fx: ctrl# = (0) 0
fx: drive# = (1) 3
which floppy type... 3.5
Then choose f(ormat) option).
Write one or more files or directories:
tar cvf /dev/rfd0 filenames
(use the proper name in place of rfd0, and write the list of files and directories in place of "filenames" )
Append:
tar rvf /dev/rfd0 filenames
List:
tar tvf /dev/rfd0
Extract:
tar xvf /dev/rfd0
Copy a .tar file (shorter then the disk) to a disk:
cat filename.tar >/dev/rfd0
Refer to the manual of your system for differences and for other options, or use "man -k disk" for the online help, if it's installed. Obviously, there are many ways to avoid typing those easy-to-forget parameters and any old UNIX user will tell you about them.
The original tar utility can't create an archive longer than a single disk, maybe that was a reasonable limit on tapes but it's not on floppy disks, we happened to download more than 10 MegaBytes of public domain files at one time (or a single file of more than 4 Mbytes) and to manually distribute files among the disks, without exceeding the 1440K limit on each, is really tedious; to split files bigger than 1440K is even more tedious.
Using multi-volume archives is almost a necessity. Any multi-volume program allows an archive to span any number of disks, when a file does not fit in a disk it writes as much data as fits and continues writing the remaining data onto another disk. The splitted files will be recombined when extracting. There are at least three different multi-volume formats (two different extensions of tar and a new program), and all these three formats are fully supported by suntar.
The non-tar program is bar, which might be part of the set of utilities which came with your UNIX (on the SPARCstation it was so, but it's no more present in Solaris). Bar generates archives in a format similar to the tar format, but data fields are placed in a different order, hence the two formats are incompatible. To run bar, simply replace tar by bar in previous examples. Really, bar was badly designed (if a data field happens to be written in a wrong way one should correct the problem, not let the extraction routine ignore that field), and the documentation of its format is full of errors, but according to our experience suntar succeeds to read bar archives without problems.
The POSIX committee has devised a multivolume format, which requires no special parameters to be used, and for example the tar bundled with AIX for the IBM RISC/6000 follows it. But remember that only the first disk has an header in a fixed place, hence POSIX tar is the only format which obliges you to always insert all the disks in the right order (you should always place a label on the disks with the archive name and disk number, since those informations are not stored inside). Single volume archives generated by POSIX tar (or GNU tar, without the V option) are fully compatible with any version of tar, the difference arises only for archives composed of more than one disk.
Really, I've seen an utility called "vol" which solves the problem of POSIX tar: it exploits the pipes of UNIX in order to add its own volume headers to archives, while tar believes that the device has an infinite length, so any single-volume tar is OK: unfortunately the documentation of vol states that it's part of QNX (a UNIX-like OS) and is not available to other UNIX users, furthermore the format of vol is far from being perfect: I wrote a clone of vol but did not test it, and anyway I did not improve it, a thing which is a necessity. Does anybody want to continue the job ? When a "standard" version of vol will exist, suntar should support it.
Really, POSIX also states that tar and cpio should be merged into a single program, "pax": GNU cpio follows that rule by supporting the tar format (including long names).
Then there is the GNU tar. GNU is an association which freely distributes a set of UNIX utilities compatible with the original ones, in source code: you may get them by anonymous ftp at prep.ai.mit.edu. The GNU version of tar has a few extra options, by specifying M it allows multi-volume archives (that is, type cvfM, rvfM, tvfM, xvfM as parameters); an extra parameter V may be used to assign a label and sequence number to disks. GNU tar does not eject the disks when they are full, hence if the drive hasn't an eject button you must have a shell prompt to issue the eject command. When GNU tar is waiting, you may type ? to get help and ! to get a sub-shell, but if you are annoyed of that, there should be a "--new-volume-script" option, which should refer to a file containing:
#!/bin/sh
eject
echo -n "Insert next floppy and press <Return> "
read dummy
If that does not work (maybe you use an older version of GNU tar) you may edit the source code so that the function "new_volume" in buffer.c looks like this:
...
else for(;;) {
{ /*addition by Sauro Speranza, 24 oct 1991 and 2 apr 1992 */
int len = strlen(ar_file);
while(ar_file[len-1] != '/' && len > 0) len --; /* strrchr is not always available */
if( !strncmp(&ar_file[len],"rfd",3) || !strncmp(&ar_file[len],"fd",2) ){ /* on the
SPARCstation or RISC/6000, anyway the strings must be the letters in
the device name, the numbers are the string lengths*/
if(ar_file[0] == '/') /* /dev/device */
system("eject");
else { /* host:/dev/device */
char cmd[300];
register char *p = ar_file;
register char *d;
strcpy(cmd,"rsh ");
d=cmd+strlen(cmd);
while( *p && *p != ':' )
*d++ = *p++;
*d = '¥0';
if( *p==':' ){
strcat(cmd," eject");
system(cmd);
} else
system("eject");
}
}
} /* end of addition */
fprintf(msg_file,"¥007Prepare volume #%d and hit return: ",volno);
...
If you want GNU tar and your tar does not come from GNU (if it does, "tar +version" will print a copyright notice), remember to get the help of an experienced programmer, the source code was written to be portable among several machines (even MS-DOS) but you must taylor some #define's to your system and maybe find where some .h files are; and if your C compiler follows the ANSI standard, try to disable all the new features: portability of source code for UNIX systems is not perfect, it's difficult to do better than that.
Finally, a new source of incompatibilities arised when people realized that the 99 characters limit for the pathname is really too small, now that UNIX names are no more restricted to 14 characters. So POSIX extended the limit to 256 characters, and GNU tar 1.11 to infinite; unfortunately, the two extensions are totally different and we had to modify suntar in order to accept both (with GNU tar, we have placed a limit of 512).
(continues in another file: sorry, but this documentation was becoming bigger than SimpleText can handle)
